This is inconsistent with multiselect - that does include groups to filtering results text. Most importantly, the filtering also works inconsistently: in multiselect one can filter for the group name, e.g. "Group 1" - it then shows all items that belong to this group. Why is this different in the button dropdown? E.g. in the demo I type "Edit" to the filter to find all items that belong to the "Edit" category. The result is empty though.

Oh, good callout. I don't know what the intended behavior should be here actually, need to confirm with design. We had this behavior implicltly from the original prototype and signoff but I don't know if this was ever discussed.

But I would imagine behaving like select/multiselect could be pretty unhelpful here, especially for really large dropdowns (like with EC2), where typing in "instance" would get you an really big list of items rather than a specific action you were maybe looking for.

Let's assume this is correct for now, but I won't merge until I get an approval on this specific behavior from the designer.

I think this can be misleading. E.g. when I search for "Security" in your demo - it matches one item our of two that are defined inside the "Security" group - because that one happens to have "security" keyword in the description. It is true that matching groups can result in many items in the output - but this can be mitigated by clarifying the input, e.g. saying "change security" or "security groups" would then find the item alone, no longer matching every item in the group.

The trouble is also that it's not consistent. For nested expandable groups (for example: "Networking" in the nested expandable group demo in the filtering dev page), the inner group name is intentionally discarded when filtering, because we don't want to have nested flattened groups. So the outer group name is filterable, but the inner one isn't. For example, typing in "Diagnostics" in the nested demo gets you no results. The alternative is to match the items under the nested group, but not show the parent group, which makes it equally confusing why they were matched.

Had a chat with the designer and decided to keep this behavior.

• This (group filtering) wasn't part of the initial scope internal or in discussion with the building team. Adding this (especially having to re-address the group "collapsing" topic we already had an agreement on earlier) is going to expand the scope for no clear use-case.
• The component is different to select and multiselect; the use-case of getting to specific actions without digging through menus is different to the select/multiselect components more "exploratory" use-case.
• Because the API for this is pretty opaque, we could treat this as a two-way door to introduce in the future if we really had strong data pushing us to do so. And this ("auto" filtering) is just a stepping stone to supporting more complex filtering in the future.

what is the purpose of checking for different item types now that filtering text is passed as a separate arg?

Test coverage! This logic is actually duplicated three times, and each test tests a different place where the check is defined.

Not sure how much sense deduplicating it makes, it's just one additional prop in the event handler call.

Can we have a single test then that defines a button dropdown featuring all item types?

Sure. But to make sure callback assertions are correct, I still need to trigger each item individually. So not much is deduplicated.

nit: I would either make filteringText required, or remove filteringEnabled in favour of filteringText !== undefined check.

Felt it was cleaner this way to have a boolean rather than combining these two attributes into an | undefined union. hasFiltering is easy to determine at the top-level from the filteringType prop, and for child elements, it's easier to pass the boolean straight through to effect dependencies (for example: expandable-category-element.tsx) rather than create a separate variable (const hasFiltering = filteringText !== undefined) just for effects (reversing additional logic in use-button-dropdown.tsx, which would need to set filteringText: hasFiltering ? filteringText : undefined).

Don't feel super strongly about this though, it's just a minor refactor. Let me know if that makes sense or you'd still prefer condensing this into one state variable.

nit: I think this comment is redundant as the code is clear enough

The comment describes what the hook does internally; easy to check the source, but I felt it important to call out here, since a seemingly innocent refactor to not match the existence of the element with the existence of the id could create an accessibility issue.